home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group93b.txt / 000039_icon-group-sender _Wed Apr 28 12:27:37 1993.msg < prev    next >
Internet Message Format  |  1993-06-16  |  3KB
  1. Received: by cheltenham.cs.arizona.edu; Wed, 28 Apr 1993 12:33:19 MST
  2. From: mitch@roll.csd.sgi.com (Tom Mitchell)
  3. Message-Id: <9304281927.AA17778@roll.csd.sgi.com>
  4. Subject:  Re: runtime debugger and the Icon fan club.
  5. To: icon-group@cs.arizona.edu
  6. Date: Wed, 28 Apr 1993 12:27:37 -0800 (PDT)
  7. X-Mailer: ELM [version 2.4 PL3]
  8. Content-Type: text
  9. Content-Length: 2370      
  10. Status: R
  11. Errors-To: icon-group-errors@cs.arizona.edu
  12.  
  13.  
  14.  
  15. There has been a 'discussion' that Icon could have a wider
  16. circle of users.
  17.  
  18. |>
  19. |does not cater to the introductory CS course regimen.  Icon has, as its
  20. |natural constituency, people interested in AI, NLP, text, translation,
  21. |and general nonnumeric computing.  Intro CS courses are.....
  22.  
  23.  
  24. I see a couple of things.
  25.  
  26. I suspect that this is a generic problem with the mind set
  27. of education today.  Consider the transition from slide rule
  28. to calculator.  There was a lot of resistance to calculators
  29. because people felt that understanding slide rules of itself
  30. is important.  I heard this in in a chem class no less.
  31. There are still art schools that demand that students grind
  32. their own paint and pigment.  Bletch... I think.
  33.  
  34. I wonder, since Icon is implemented in 'C' it might be considered 
  35. dependent on 'C' and thus less interesting.  Also given that there
  36. is also a strong bias toward stronger type defines in ANSI 'C',
  37. the lack of type checking in Icon could be seen as a loss 
  38. against the curriculum goals.
  39.  
  40. A real power of Icon is the ease of expressing things like
  41. generators.  Should these be taught before or after
  42. recursion in a CS course, message passing, object oriented
  43. programming?  Should the implementation of generators in c,
  44. Fortran, assembler be a CS goal.
  45.  
  46. I believe that a general purpose language does need to
  47. be 'invented' that defines an expressive context to permit
  48. strong type checking, object hiding, generators, lists,
  49. multi-dimension arrays, bounds checking etc.
  50.  
  51. Just in case should some one sets out to do this. An
  52. irritant to me is little inconsistent 'features' like {} and ; 
  53. omissions where the parser can permit such things to be
  54. omitted in one place and not in others.  I find that they
  55. are a problem to me learning a language or using a language
  56. infrequently.  We all like to start with simple examples
  57. that illustrate something.  These are also the examples that
  58. permit shortcuts.  When I expand from the trivial example to
  59. something interesting I find I now need the missing {}; and 
  60. wish they were there in the example the start.
  61.  
  62.  
  63. Sort of a summary:
  64.  
  65. Does Icon support these goals in the first two years of a CS
  66. education?  Mostly not I suspect.
  67.  
  68. What are the curriculum goals of a CS education?  What are
  69. the education goals of a non CS education.
  70.  
  71. Does Icon support the CS needs of a non-CS education?
  72. Mostly not I suspect.
  73.  
  74.  
  75.  
  76.  
  77.  
  78.